This chapter provides the steps needed to create a basic configuration of a SpinServer system, including the configuration of the SpinServer and the SpinStor 200. The steps provided in this chapter are examples; for more information on any of the steps, see the full description of each command in the following chapters.
The SpinManager CLI is used in the command examples. The SpinManager GUI has the same commands in the same hierarchy.
To complete the administration tasks discussed in this chapter, use one of the options described in Chapter 4 .
A console connected to the serial port (COM1) is needed to access the SpinManager CLI.
Note: Only the CLI is available to access the SpinManager when using a direct connection through the serial port.
With the console connected, press Enter twice. At the Login prompt, type admin. At the Password prompt, type admin.
After logging in, the prompt (SpinServerID::>) is displayed. You are ready to continue the configuration tasks for the SpinServer. For the examples in this section, Server1 is the SpinServer ID and is used in the SpinServer prompt in the command examples.
Note: To change the login password, see Section 5.4.1.
You can set up secure access to the SpinManager GUI by configuring HTTPS on the SpinServer system. By default, SpinFS Version 2.1 uses HTTPS for GUI connections.
By default, the SpinServer uses a self-signed Secure Sockets Layer (SSL) certificate. To use another certificate (for instance, a certificate from VeriSign), log onto the SpinServer as root and copy the certificate to /var/spinmgmt/keys/spinmgmt.pem. Contact Network Appliance Technical Support for assistance. The self-signed SSL certificate is valid for 365 days from installation.
The first time you use Internet Explorer to access the SpinManager GUI, the browser can generate the following warning: Information you exchange with this site cannot be viewed or changed by others. However, there is a problem with the site's security certificate. To install the certificate into Internet Explorer and avoid this message on subsequent sessions, perform the following steps:
Click View Certificate on the Security Alert dialog box. A new dialog box opens.
Click Install Certificate.
Complete the certificate installation with the defaults provided by the dialog box.
Click OK on the Security Alert dialog box.
The first time you use Netscape or Mozilla to access the SpinManager GUI, the browser can generate the following warning: Unable to verify the identity of SpinServer as a trusted site. To install the certificate into the browser and avoid this message on subsequent sessions, perform the following steps:
On the dialog box, select Accept this certificate permanently and click OK.
The browser can generate the following message: You have attempted to establish a connection with SpinServer. This message is displayed only if the SpinServer's name is different from that contained in the certificate; for example, if the SpinServer's name is System1.lab but the name in the certificate is listed as System1. If this message appears, click OK on the dialog box.
The browser can generate the following warning: You have requested an encrypted page that contains some unencrypted information. To disable this warning, click Edit → Preferences, then open Privacy and Security → SSL. Under SSL Warnings, clear the Viewing a page with an encrypted/unencrypted mix check box and click OK.
Command examples are given to illustrate the configuration process. For the command examples, the information obtained from a network administrator is given below.
Table 6-1. SpinServer Configuration Example
| SpinServer ID | Server1 |
| Management IP address (if not using DHCP) | |
| Management netmask (if not using DHCP) | |
| Management default gateway IP (if not using DHCP) | |
| Management primary name server (if not using DHCP) | |
| Server IP address 1 | 10.1.1.140 |
| Server netmask 1 | 255.255.255.0 |
| Server IP address 2 (optional) | |
| Server netmask 2 (optional) | |
| Cluster IP address 1 | 192.168.66.1 |
| Cluster IP address 2 (optional) | 192.168.66.2 |
| Cluster netmask | 255.255.0.0 |
| Cluster broadcast | 192.168.255.255 |
Before configuring the SpinServer, you can check the SpinServer identification information that was entered at the time the software was installed. To do this, use the spinservers show command.
To display information about the SpinServers in the system, use the following command.
Server1::> spinservers show
Initialization of a SpinServer involves creating a new cluster or joining an existing cluster. Every SpinServer is part of a cluster, and although the cluster can contain only a single SpinServer, every SpinServer must be entered into a cluster before any other system management task is undertaken.
The spinservers createcluster and spinservers joincluster commands cause other system operations to take place. Both commands take the IP configuration for the cluster ports. This information is then stored in the interface configuration page after the node has completed the create or join cluster operation.
The spinservers joincluster command uses the cluster IP address of a SpinServer already in the cluster that you want another SpinServer to join. This SpinServer must be healthy and in active communication with the cluster. It can be any healthy host within the cluster.
Note: The spinservers createcluster and spinservers joincluster commands can take up to 30 seconds to complete.
To initialize SpinServer Server1, use the spinservers createcluster command, as shown in the following example.
Server1::> spinservers createcluster -ssid Server1 -clustername Cluster1 -ipaddress1 192.168.66.1 -ipaddress2 192.168.66.2 -netmask1 255.255.0.0 -broadcast1 192.168.255.255
where
Server1 is the ID given to the SpinServer.
Cluster1 is the name of the new cluster.
192.168.66.1 is the IP address of the first cluster interface.
192.168.66.2 is the IP address of the second cluster interface. It is optional.
255.255.0.0 is the netmask of the cluster network.
192.168.255.255 is the broadcast IP address. The broadcast IP address is needed only if the default is known to be insufficient.
For more information about this command, see Section 8.2.1 .
The spinservers joincluster command can be used to initialize additional SpinServers that you want to add to an existing cluster. The spinservers joincluster command is different from the spinservers createcluster command in that it uses the cluster IP address of a SpinServer already in the cluster.
Important: This command must not be used for any other purpose. If you mistakenly run the spinservers createcluster command instead of the spinservers joincluster command, you must reinstall the SpinServer (or completely delete all configuration data) to undo the operation. Before you reinstall the SpinServer or delete any configuration information, contact Network Appliance Technical Support.
The following example adds a SpinServer named Server2 to the cluster that was created in the preceding example.
Server1::> spinservers joincluster -ssid Server2 -clusternodeipaddress 192.168.66.1 -ipaddress1 192.168.66.3 -ipaddress2 192.168.66.4 -netmask1 255.255.0.0 -broadcast1 192.168.255.255
where
Server2 is the ID given to the SpinServer that is added to the cluster.
192.168.66.1 is the cluster IP address of a SpinServer already in the cluster that you want Server2 to join. This SpinServer must be healthy and in active communication with the cluster. It can be any healthy host within the cluster.
192.168.66.3 is the IP address of the first cluster interface.
192.168.66.4 is the IP address of the second cluster interface. It is optional.
255.255.0.0 is the netmask.
192.168.255.255 is the broadcast IP address. The broadcast IP address is changed only if it is known to be insufficient.
For more information about this command, see Section 8.2.2 .
Note: After running the spinservers joincluster or spinservers createcluster command, you can use the spinservers modify command to further identify the SpinServer by entering this additional information: owner, contact information, asset tag, and location of the SpinServer. For additional information about this command, see Section 20.2.2.
A virtual interface is named by the user and associated with a network port. You need to give some thought to the names you choose so that when other network virtual interfaces are added to your system, the names are orderly and recognizable. See your network administrator if you have questions about the naming scheme to be used in the SpinServer system.
The if configuration new command creates an interface and identifies it by its unique SpinServer ID and interface name.
Use the if configuration new command to create a virtual interface, as shown in the following example.
Server1::> if configuration new -ssid Server1 -ifname if0 -netportname serv0 -ipaddress 10.1.1.140 -netmask 255.255.255.0
where
Server1 is the ID given to the SpinServer.
if0 is the name of the new interface.
serv0 is the name of the physical port to which the new virtual interface is bound.
10.1.1.140 is the IP address you assigned to the new interface.
255.255.255.0 is the netmask you assigned to the new interface.
For more information about this command, see Section 9.2.1.
If you have purchased the optional SpinHA software, perform the following step to configure the SpinServer system for high availability (HA):
Use the if configuration addfailoverport command to set Server1's virtual interface to fail over to Server2.
Failover ports are critical components of HA configurations. Use the if configuration addfailoverport command to set Server1's virtual interface to fail over to Server2, as in the following example:
Server1::> if configuration addfailoverport -ssid Server1 -ifname if0 -ssidto Server2 -netportnameto serv0
where
Server1 is the ID given to the SpinServer.
if0 is the name of the virtual interface on Server1.
Server2 is the name of the SpinServer with the failover port.
serv0 is the network port that is designated as a failover port on Server2.
For more information about this command, see Section 9.2.9. For more information about HA configurations, see Basic Concepts of the SpinServer Architecture.
All of the disks in a single RAID enclosure, along with the disks in any attached expansion enclosure, are controlled by the pair of RAID controllers in the RAID enclosure. This pair of RAID controllers and their attached disks form a single RAID subsystem. The SpinServer has as many RAID subsystems as it has SpinStor 200 RAID enclosures.
Each RAID subsystem is configured individually. By using the management software, you can identify which disks belong to which RAID subsystem, and the disks' states. Normally, individual disks can be part of a RAID set, be used as a hot spare, or be uncommitted. A disk cannot belong to more than one RAID set.
RAID subsystems must be configured with individual disks of the same speed, but can use individual disks of different capacities. However, if you mix disks of different capacities in a RAID set, the SpinServer uses all disk drives in the RAID set as having the same capacity as the smallest disk drive in the RAID set. The remaining disk drive capacity is not used.
Important: This section describes the configuration of RAID components when SpinStor 200 RAID enclosures are used. SpinStor 200 enclosures are used only with legacy SpinServer systems. For information on configuring the RAID components of a new SpinServer system that uses FAS270c RAID enclosures, see the Data ONTAP documentation, including the Block Access Management Guide for FCP and Storage Management Guide.
Note: When using disks of different sizes in the same RAID set, any disk designated as a hot spare must be of the larger disk size.
Note: If a disk drive is replaced with a disk drive of a larger capacity, the raid diskdrive show command displays the capacity of the original disk drive instead of the new larger disk drive size until the system is rebooted.
The SpinServer supports the following RAID levels:
RAID 0—This level supports a striped disk array, but without fault tolerance. A RAID 0 RAID set must include at least two disks.
RAID 1—This level supports mirroring. A RAID 1 RAID set must include only two disks.
RAID 3—This level supports parallel data transfer with parity. A RAID 3 RAID set must include at least three disks.
RAID 5—This level supports independent data disks with distributed parity blocks. A RAID 5 RAID set must include at least three disks.
RAID 0+1—This level supports high performance of data transfer. A RAID 0+1 RAID set must include at least four disks.
All RAID levels combine a set of disks to form a RAID set. A RAID set is a group of disks that work together to form a logical disk that is larger, faster, and more reliable than the individual disks. After a RAID set has been created, it can be configured as one large, fast disk for the purpose of setting up file systems.
With a hot spare disk available, the RAID controller can reconstruct the data that is stored on a failed disk by placing the data on the hot spare. After this rebuilding process is complete, the RAID set regains its performance and reliability.
Note: If a hot spare is not available, the RAID set cannot be rebuilt until the failed disk is replaced with a new disk.
There can be more than one hot spare disk in a RAID subsystem. In this case, when a hot spare is needed to rebuild a RAID set, the choice is arbitrary as to which hot spare disk is used. The hot spare does not need to be physically located near the rest of the RAID set.
An uncommitted disk is available to be combined with other uncommitted disks to form a RAID set or to be designated as a hot spare.
If your SpinServer system includes RAID sets that were preconfigured at the factory, they are ready for you to use to create storage pools and virtual file systems. If the RAID sets were not preconfigured, you must configure and initialize the RAID sets.
Before proceeding with the configuration and initialization of the RAID sets, the current disk configuration must be reviewed. To review the disk configuration, use the raid diskdrives show command. Each of the recognized disks is identified in the Device field by its RAID subsystem (rn, where r stands for RAID subsystem) and its disk ID (dn, where d stands for disk). See Section 10.2.3.1 for more information about this command.
If the RAID sets and disks are already configured as needed for your system, then no more RAID configuration is necessary. However, if your system requires additional RAID sets, they must be configured and initialized as described in the following section.
Before using a RAID enclosure, confirm that it is in the expected configuration by checking the following:
Determine that the target numbers of all of the disks match the target numbers set on the disk enclosure. Use the following formula to determine the target numbers:
Disk ID = 2 x target number + default channel number
To review the target numbers of the disk drives, use the raid diskdrives show command. For additional information about setting the target numbers, see the Installation Guide.
Determine that several disks in each enclosure can be correctly located by using the raid diskdrives locate command. See Section 10.2.3.2 for information.
Determine that RAID sets can be correctly located as they are created by using the raid sets locate command. See Section 10.2.1.5 for information.
Determine that the enclosure's temperature, power supply, and blower monitoring functions are working by observing the Fault LEDs on the enclosure and by using the raid enclosures show command. See Section 10.2.4.2 for information.
Determine that half of the disks in each enclosure are using Channel 0 and the rest are using Channel 1 by using the raid diskdrives show command. See Section 10.2.3.1 for information.
Determine that all of the RAID controllers' status is Active by using the raid controllers show command. Critical status is not acceptable during initial configuration. See Section 10.2.5.1 for more information.
You must create RAID sets before you create storage pools.
The device identification for a RAID set is in the format rsubsystem_numbersraidset_number, where subsystem_number indicates the RAID subsystem and raidset_number indicates the specific RAID set.
If the SpinServer system does not include RAID sets that were preconfigured at the factory or if you are adding a new RAID enclosure to the system, your first step is to create a RAID set. The RAID set will be online after you create it because you designate its status as online.
Note: When the first RAID set is created on a RAID subsystem, the creation process can take as long as two minutes. The process takes this long to create the first RAID set on a RAID subsystem because a reset command is issued to the RAID controllers after the creation process is completed. The reset is necessary because the strip size and cache line size are updated from the previous settings. This type of change requires the RAID controllers to be reset. If the RAID set on a RAID subsystem is not the first one created, the creation process is completed in a shorter time period.
To create a RAID set, use the following command with a list of the disks that you want to be included in the RAID set.
Server1::> raid sets new -raidlevel 5 -stripsize 16 -writecacheenabled false -status Online -disks [r0d1, r0d2, r0d5, r0d6, r0d9, r0d10, r0d13, r0d14, r0d17, r0d18, r0d21 r0d22, r0d25, r0d26, r0d29]
where
5 is the RAID level.
16 is the RAID strip size in KB. The default setting is 8 KB. Other setting options are 16 KB, 32 KB, or 64 KB. A RAID strip is a piece of a single disk that is used for data storage. A RAID stripe is a set of the corresponding strips from all of the disks in a RAID set. The RAID strip size must match the RAID strip size that is currently set on the RAID controller.
false disables the write cache. This is the default setting for the write cache. Enabling the write cache with a value of true can result in higher system performance but can cause the loss of data if an error occurs.
Online is the status of the RAID set.
[r0d1, r0d2, r0d5, r0d6, r0d9, r0d10, r0d13, r0d14, r0d17, r0d18, r0d21 r0d22, r0d25, r0d26, r0d29] are the disk IDs of the disks to be included in the RAID set.
Note: If you make mistakes in the configuration of a RAID set, you must delete the RAID set. RAID sets cannot be deleted randomly. The RAID set created most recently must be deleted first.
See Section 10.2.1.1 for more information about this command.
After RAID sets are created and configured, initialization of the RAID set begins as a background process upon first use of the RAID set. For example, if you create storage pools and assign storage units (RAID sets) to the storage pools, background initialization automatically starts.
As background initialization proceeds, you can use one of the storage pools to create a virtual server. After the virtual server is created, you create a virtual interface, specifying an appropriate IP address and netmask. After creating and mounting a virtual file system, you can write data to the RAID set as background initialization continues.
Note: Background initialization can be a lengthy process. It can take about 1 hour for every 70 GB of disk capacity. For example, initializing a 240-GB RAID set can take about three and one-half hours. However, as noted previously, you can use this RAID set while the initialization is in progress.
See Section 10.2.1.7 for more information about background initialization. Alternatively, for information about foreground initialization, see Section 10.2.1.10.
The raid diskdrives makehotspare command identifies a given disk by its disk ID and designates its status as a hot spare in a RAID subsystem. A hot spare is a replacement disk that can be used to rebuild all user data from a failed disk in the RAID subsystem. Use the command to create as many hot spares as the RAID subsystem requires.
Note: Disks configured as hot spares can protect RAID sets only on the same RAID subsystem.
To create a hot spare for a RAID subsystem, use the following command:
Server1::> raid diskdrives makehotspare -deviceid r0d26
where
r0d26 is the disk ID for the disk designated as a hot spare in the RAID subsystem r0.
See Section 10.2.3.4 for more information about this command.
After setting up the disk enclosure, use the raid diskdrives show and raid sets show commands to check that all of the disks and RAID sets are correctly configured and initialized. If the configuration is incorrect, you can use raid commands to modify the configuration. See Section 10.2 for more information.
A storage pool is a logical grouping of physical storage. Storage pools are comprised of one or more storage units. A storage pool can be comprised of 1 to 128 storage units. A single storage unit represents a single external RAID set or a single JBOD disk, providing a much larger block address space than is possible with only one RAID set or one JBOD disk. The functional purpose of a storage pool is to serve as a logical container for virtual file systems (VFSs).
If you have purchased the optional SpinHA software and have configured your system for high availability, each storage pool is served by one primary SpinServer and one or more secondary servers so that the SpinServer system has no single point of failure. The primary SpinServer for a storage pool controls the read and write operations for the storage pool. If the primary SpinServer fails, one of the secondary SpinServers assumes control of the storage pool.
The SpinServer on which the storage pool is created becomes the primary SpinServer for that storage pool.
Before setting up a storage pool, use the storage units show command to obtain the storage unit names assigned by the system. This command provides a view of the external RAID sets or JBOD disks as seen from the Fibre Channel host bus adapters (HBAs).
The following command example displays configuration information about all storage units. After identification of the storage units has been made, the following information is displayed: device ID, World Wide name, logical unit number (LUN), file system device ID, channel status, primary loop ID, secondary host channel status, secondary host channel, secondary loop ID, RAID set ID, type, vendor, product, revision number, status (online, offline, or unused), damaged status (true or false), error status (true or false), last error code, error description, and storage space size (in GB) on the storage unit.
Server1::> storage units show
See Section 11.2.1 for more information.
A storage pool is named by the user. Any assigned name can be chosen as long as it is unique within a cluster. To create a storage pool, use the storage pools new command, as in the following example. Depending on the number of physical disks that are included in the RAID sets that are being used, this command can take several minutes to complete.
Server1::> storage pools new -deviceid sp0 -layout stripe -freespacealarm 10 -sunits [su0,su1,su2]
where
sp0 is the name or ID you assigned to the storage pool you created.
stripe is the configuration of the storage pool.
10 specifies the percentage of free space remaining on the storage pool before the free-space alarm is triggered.
[su0,su1,su2] is the list of storage units (RAID sets) assigned to the storage pool you created.
See Section 11.2.4 for more information.
After creating a new storage pool, for HA, you must designate a passive secondary SpinServer for the storage pool and then promote that passive secondary to an active secondary. See Section 11.1.1 for general information about high availability.
Add a SpinServer named Server2 as a passive secondary by using the storage pools addpassivesecondary command, as in the following example.
Server1::> storage pools addpassivesecondary -deviceid sp0 -passivesec Server2 -priority 1
where
sp0 is the name or ID of the storage pool.
Server2 is the SpinServer to be added as a passive secondary server for the storage pool.
1 is the takeover priority of the passive secondary server.
See Section 11.2.15 for more information.
Promote Server2 as an active secondary by using the storage pools promotepassivesecondary command, as in the following example.
Server1::> storage pools promotepassivesecondary -deviceid sp0 -passivesec Server2
where
sp0 is the name or ID of the storage pool.
Server2 is the SpinServer to be promoted as an active secondary server for the storage pool.
Note: If the number of active secondary servers for the storage pool is set to greater than zero, the first passive secondary server that was created is automatically promoted to active secondary.
See Section 11.2.17 for more information.
Before creating a virtual server or VFS, you can define Network Information Service (NIS) or CIFS domains. Defining NIS or CIFS domains at this point in the configuration process provides you with the opportunity to specify the ownership of the new VFS by name rather than by number. Also, CIFS domains are required for the CIFS protocol, and NIS domains are required for performing mapping of CIFS users to NFS users, and for NFS access via Kerberos.
Note: Domain configuration can be omitted if your site does not use NIS or CIFS, or if you would prefer to do the domain configuration later.
NIS is widely used to provide simple name network lookup service and user authentication service. Its purpose is to provide information that needs to be available to the entire network, such as login names, passwords, home directories, and group information.
The SpinServer system's virtual servers can use NIS to translate NFS user IDs to names and vice versa. This process enables you to specify the owner of a VFS by name (rather than ID), and can be used to support mapping of CIFS users to NFS users. Your first task is to specify the NIS domains to be used.
Use the spinaccess nfs domains new command to specify the NIS domains to be used by identifying their domain names and NIS servers to be used for the domain. The NIS server option for this command specifies a comma-separated list of NIS servers that handle NIS requests for the specified domain. If the option is omitted, a broadcast search is used to look for a NIS server for the domain.
Note: To configure a NIS domain at this point, it is assumed that the NIS server's IP address is on the same subnet as the management port (mgmt0). If the NIS server's subnet is the same as the subnet connected to the network ports (serv0 and serv1), then a virtual server and a bound virtual interface must first be configured for the subnet. See Section 6.9.1 and Section 6.10 for details.
Use the following command to specify a NIS domain.
Server1::> spinaccess nfs domains new -domainname acmebricks.com -nisservers [10.2.2.1, 10.3.3.1]
where
acmebricks.com is the NIS domain name.
[10.2.2.1, 10.3.3.1] is the square-bracketed, comma-separated list of NIS servers.
See Section 15.2.1.1 for more information.
To define the CIFS domain, use the spinaccess cifs domain new command. CIFS virtual servers, which are created later in this configuration process, must exist within a CIFS domain as defined here. By configuring the CIFS domains, you inform the SpinServer of the Windows NT and Windows 2000 domains that exist on the network. You must enter every CIFS domain on the network that users use to access the SpinServer.
Note: Domain names, domain controller names, and NetBIOS names can be up to 15 characters long. The SpinServer does not accept the fully qualified DNS name style that Windows 2000 supports. CIFS domain names are converted to all upper case when they are created.
Note: To successfully register a new domain with the SpinServer, the SpinServer must be able to contact the primary domain controller (PDC) that is specified by the -pdcname and -pdcip parameters in the command. The virtual interface that is bound to the virtual server that you plan to add to the new domain must already be running and have access to the PDC.
Note: To configure a CIFS domain at this point, it is assumed that the PDC's IP address is on the same subnet as the management port (mgmt0). If the PDC's subnet is the same as the subnet connected to the network ports (serv0 and serv1), then a virtual server and a bound virtual interface must first be configured for the subnet. See Section 6.9.1 and Section 6.10 for details.
To define a CIFS domain, use the spinaccess cifs domains new command, as in the following example.
Server1::> spinaccess cifs domains new -domainname ENG -winsip 10.1.1.116 -pdcname STORM -pdcip 10.1.1.116 -bdcname1 RAIN -bdcip1 10.1.1.118
where
ENG is the name of the CIFS domain.
10.1.1.116 is the IP address of the domain's WINS server.
STORM is the name of the domain's primary domain controller (PDC).
10.1.1.116 is the IP address identifying the PDC.
RAIN is the name of the first backup domain controller (BDC).
10.1.1.118 is the IP address of the first BDC.
Note: If you specify BDCs, the fields with the lowest values must be filled in first. For example, if you have one BDC, fill in -bdcname1 and -bdcip1. If you have two, fill in -bdcname1, -bdcip1, -bdcname2, and -bdcip2. All must be filled in before specifying a third backup domain controller.
See Section 14.2.1.1 for more information.
A virtual server represents a separate file system namespace with separate network access. When a virtual server is created, its root VFS is automatically created. To create a virtual server, use the vservers servers new command.
For more information about creating virtual servers, see Section 12.2.1.
The following command example creates a virtual server.
Server1::> vservers servers new -vsname vserver1 -spdevid sp1 -spinauth false -floatingsuperuser false -minauth none -rulesetname default_ruleset -showspinshot -true -restrictedacl false
where
vserver1 is the name or ID of the virtual server to be created.
sp1 is the name or ID of storage pool in which the new virtual server's root VFS is to be created.
false specifies that the SpinAuth authentication mechanism is not to be used on this virtual server.
false specifies that a floating superuser is not permitted on this virtual server.
none is the minimum authentication for the virtual server. Possible values are none, cifs-ntlm, cifs-kerberos, and nfs-kerberos (kerberos is accepted as a synonym for nfs-kerberos).
default_ruleset specifies the name of the export rule set that is to be applied to this virtual server.
true specifies that the .spinshot directory is visible to clients on all VFSs created on this virtual server.
false specifies that CIFS access control lists (ACLs) are used on all VFSs created on this virtual server.
After setting up a virtual server, you must bind one or more network virtual interfaces to the virtual server by using the vservers servers bindif command.
Note: As detailed earlier, the network virtual interfaces specified here must have been previously created.
The following example binds a network virtual interface to the designated virtual server.
Server1::> vservers servers bindif -vsname vserver0 -ssid Server1 -ifname if0
where
vserver0 is the name or ID of the virtual server to which the network virtual interface named if0 is bound.
Server1 is the ID given to the SpinServer.
if0 is the name or ID of the network virtual interface.
See Section 12.2.4 for more information.
This section provides instructions for setting up Kerberos for NFS or CIFS.
To enable the SpinServer to use Kerberos authentication for the NFS protocol, complete the following tasks:
Define the NIS domain in which Kerberos users are defined. This task is described in Section 6.8.1.
Define the Kerberos realm or realms that are to be used to control access to the SpinServer.
Create the virtual server. This task is described in Section 6.9.1.
Define a set of regular expressions that are to be used to map Kerberos client principal names to NIS user names.
Define the Service Principal Names (SPNs) to be used by each virtual interface that is to be enabled for Kerberos authentication.
To complete these tasks, you must obtain configuration information from your network and Kerberos administrator or administrators. Use the following table to enter the information that is needed for this process.
| NIS domain name |
For each Kerberos realm, enter the following information.
| Realm name | |
| KDC vendor | |
| KDC IP address | |
| KDC port | |
| Admin IP address | |
| Admin port | |
| kpasswd IP address | |
| kpasswd port | |
| Use DNS to find KDC | |
| DNS server IP addresses | |
| Active Directory server IP address | |
| Administrator's user name | |
| Administrator's password |
For each virtual interface, enter the following information.
| Service Principal Name |
To use Kerberos on a SpinServer, you must configure a Kerberos realm on the SpinServer by using the spinaccess kerberos realm new command, as in the following example.
Server1::> spinaccess kerberos realm new -configname eng -realm ENG.EXAMPLE.COM -kdc_vendor Other -kdc 10.1.4.55 -kdcport 88 -adminaddr 10.1.4.55 -adminport 749 -passwdaddr 10.1.4.55 -passwdport 464 -clockskew 300
where
eng is the configuration name that SpinManager uses to refer to this realm.
ENG.EXAMPLE.COM is the Kerberos realm name. Kerberos realm names are case sensitive.
Other is the Kerberos KDC vendor. Possible values for this option are Microsoft and Other. Use Microsoft only for Kerberos realms served by Microsoft Windows 2000-compatible Active Directory-based realms. Note that CIFS can be used only with Microsoft realms, while NFS can be used with either type.
10.1.4.55 is the address of the key distribution center (KDC), which, in this example, is also the admin server and kpasswd server.
88 is the KDC port number. (This is the default value.)
749 is the admin port number. (This is the default value.)
464 is the kpasswd port number. (This is the default value.)
300 is the clock skew, in seconds, permitted between clients and the server. (This is the default value.)
For more information, see Section 16.2.3.
Kerberos clients accessing files on a SpinServer via NFS must have their identities mapped to numeric IDs. This mapping is done by first applying a set of regular expressions to the clients' Kerberos principal names, and then by looking up the results of those regular expressions in NIS.
To configure this mapping, you must first associate the NIS domain and Kerberos realms with the virtual server, and then define the set of regular expressions to be used in the mapping.
Note: For further information about regular expressions, see Mastering Regular Expressions published by O'Reilly and Associates, Inc. at http://www.oreilly.com/catalog/regex. Additional information can be obtained from a UNIX prompt by running info regex. For further information and examples, run the command man 7 regex.
To associate a NIS domain with a virtual server, use the spinaccess nfs servers new command, as in the following example.
Server1::> spinaccess nfs servers new -vsname fin_svr -domainname example.com -kerbrealms [eng, finance]
where
fin_svr is the name or ID of the virtual server to be associated with the NIS domain and Kerberos realms.
example.com is the name of the NIS domain to be used for NIS lookups for this virtual server. This must be a domain that has been previously configured by using the spinaccess nfs domains commands, as described in Section 6.8.1.
[eng, finance] is the list of Kerberos realms that is visible to this virtual server. Multiple values must be separated by commas and enclosed in square brackets, as shown here. Kerberos realms in this list must have been previously configured by using the spinaccess kerberos realm commands, as described previously.
For more information, see Section 15.2.2.1.
To set up Kerberos-NIS user mappings, use the spinaccess kerb-nis new command, as in the following examples.
Server1::> spinaccess kerb-nis new -vsname fin_svr -clientpattern "[^@]+@ENG.EXAMPLE.COM" -clientpatternreplace eng_guest
Server1::> spinaccess kerb-nis new -vsname fin_svr -clientpattern "([^@/]+)(/[^@]+)?@FINANCE.EXAMPLE.COM" -clientpatternreplace \1
where
fin_svr is the name or ID of the virtual server for which these mappings are to be defined.
[^@]+@ENG.EXAMPLE.COM is the regular expression to be matched in the first mapping. (This regular expression matches any principal in the Kerberos realm ENG.EXAMPLE.COM.)
eng_guest is the replacement to be used when the pattern is matched. This first mapping, therefore, maps any principal in the Kerberos realm ENG.EXAMPLE.COM to the NIS user eng_guest.
([^@/]+)(/[^@]+)?@FINANCE.EXAMPLE.COM is the regular expression to be matched in the second mapping. This regular expression matches any principal in the Kerberos realm FINANCE.EXAMPLE.COM, and groups any set of characters up to the first / character.
\1 is the replacement to be used when the pattern is matched. The notation \1 means to replace the pattern with the first grouped set of matched characters; in this case any characters from the original client principal name before the first / character. This second mapping, therefore, maps any principal in the Kerberos realm FINANCE.EXAMPLE.COM to the NIS user corresponding to the principal's base name with any instance names removed. For example, anne/admin@FINANCE.EXAMPLE.COM becomes anne.
For more information, see Section 16.2.4.1.
A virtual interface that is to use Kerberos authentication for NFS must have a service principal name (SPN). NFS SPNs are of the form nfs/hostname@REALM, where hostname is the DNS name that clients use to mount file systems on this virtual interface (that is, the DNS name associated with this virtual interface's IP address), and REALM is the Kerberos realm name of the virtual interface.
To assign an SPN to a virtual interface for use with NFS, use the spinaccess kerberos ifconfig enablekerberos command, as in the following example.
Server1::> spinaccess kerberos ifconfig enablekerberos -ssid Server1 -ifname vif2 -spn nfs/spin1.eng.example.com@ENG.EXAMPLE.COM -uname tom/admin -passwd s3cre!
where
Server1 is the name or ID of the SpinServer on which the virtual interface is defined.
vif2 is the name or ID of the virtual interface whose SPN is to be assigned. This virtual interface must be one that has already been bound to a virtual server.
nfs/spin1.eng.example.com@ENG.EXAMPLE.COM is the Service Principal Name (SPN) for this virtual interface. Service Principal Names are case sensitive. This name must include a realm part, and it must be in a realm that is visible to the virtual server to which this virtual interface has been bound. If the principal does not already exist, the command creates it; if it does already exist, its service key is randomized.
tom/admin is the Kerberos user name of a principal with privileges to create a new principal or randomize its key in the SPN's realm. You can give a name that includes a realm part here, but if you do, it must be the same realm as the SPN's realm. If you omit the realm part (as shown here), the SPN's realm will be used.
s3cre! is the password for the tom/admin@EXAMPLE.COM account. Note that, if you are using the CLI, the password is echoed here in plain text; to mask this password as it is entered, perform this step from the GUI.
The administrative user name and password entered in this step are not stored; they are used to create the principal named by the SPN (or to randomize its key) and are then discarded.
If you use a single DNS name to refer to multiple IP addresses, you can use the same SPN for multiple virtual interfaces. If you do, the key is not rerandomized for each virtual interface, and the administrator's user name and password can be omitted when setting SPNs for the second and subsequent virtual interfaces.
For more information, see Section 16.2.5.
To enable the SpinServer to use Kerberos authentication for the CIFS protocol, complete the following tasks:
Define CIFS domain settings for the target domain. This task is described in Section 6.8.2.
Define the Kerberos realm or realms that are to be used to control access to the SpinServer.
Set up a CIFS domain for Kerberos authentication and account management.
Create a CIFS virtual server in the target domain or realm.
To complete these tasks, you must obtain configuration information from your network and Kerberos administrator or administrators. Use the following table to enter the information that is needed for this process.
| CIFS domain name |
For each Kerberos realm, enter the following information.
| Realm name* | |
| KDC vendor | |
| KDC IP address | |
| KDC port | |
| Admin IP address | |
| Admin port | |
| kpasswd IP address | |
| kpasswd port | |
| Use DNS to find KDC | |
| DNS server IP addresses | |
| Active Directory server IP address | |
| Administrator's user name | |
| Administrator's password* |
For each CIFS virtual server, enter the following information:
| NetBIOS host name | |
| Service Principal Name* | |
| SPN account initial password* |
*These parameters are case sensitive and must be entered accordingly. CIFS realm name and Service Principal Name must always be typed in full uppercase, as they are in the previous examples.
To use Kerberos on a SpinServer, you must inform the SpinServer about the configuration details of the Kerberos realm. To do this, use the spinaccess kerberos realm new command, as shown in the following example.
Server1::> spinaccess kerberos realm new -configname mykerbrealm -realm MYDOMAIN.COM -kdc_vendor Microsoft -kdc 10.10.10.0 -kdcport 88 -adminaddr 10.10.10.0 -adminport 749 -passwdaddr 10.10.10.0 -passwdport 464 -clockskew 300
where
mykerbrealm is the configuration name that SpinManager uses to refer to this realm.
MYDOMAIN.COM is the Kerberos realm name. Kerberos realm names are case sensitive.
Microsoft is the Kerberos KDC vendor. Possible values for this option are Microsoft and Other. Use Microsoft only for Kerberos realms served by Microsoft Windows 2000 compatible Active Directory-based realms. Note that CIFS can be used only with Microsoft realms, while NFS can be used with either type.
10.10.10.0 is the address of the KDC, which, in this example, is also the admin server and kpasswd server.
88 is the KDC port number. (This is the default value.)
749 is the admin port number. (This is the default value.)
464 is the kpasswd port number. (This is the default value.)
-clockskew 300 is an optional parameter that the defines the amount of time, in seconds, that the clocks on Kerberos clients can differ from the SpinServer. If the clocks differ by more than this amount, clients fail Kerberos preauthentication. (This is the default value.)
For more information, see Section 16.2.3.
Windows 2000 clients that participate in the Windows Domain Security Model can take advantage of Kerberos-style authentication. A SpinServer can authenticate clients that attempt to use its resources by using the Kerberos tickets that are presented by the client when attempting to access resources that are shared by the SpinServer. To accomplish this, the SpinServer must know the Kerberos realm and the Windows domain to which it belongs. These values are often the same.
The following example creates a Windows domain that uses Kerberos authentication.
Server1::> spinaccess cifs domains new -domainname MYDOMAIN -winsip 10.10.10.0 -pdcname mypdc -pdcip 10.10.10.0 -kerbconf mykerbrealm
where
MYDOMAIN is the CIFS domain to be modified with Kerberos configuration information.
10.10.10.0 is the (optional) address for a WINS server in the target domain.
mypdc is the name of the Primary Domain Controller in the target domain.
10.10.10.0 is the IP address of the Primary Domain Controller in the target domain.
mykerbrealm specifies the Kerberos configuration that is to be associated with the CIFS domain. You must specify a Kerberos configuration whose KDC vendor type is Microsoft.
For more information, see Section 14.2.1.1.
The following example specifies that an existing Windows domain use Kerberos-style authentication by binding a Kerberos realm to the CIFS domain.
Server1::> spinaccess cifs domains modify -domainname MYDOMAIN -kerbconf mykerbrealm
where
MYDOMAIN is the CIFS domain to be modified with Kerberos configuration information.
mykerbrealm specifies the Kerberos configuration that is to be associated with the CIFS domain. You must specify a Kerberos configuration whose KDC vendor type is Microsoft.
For more information, see Section 14.2.1.3.
A CIFS virtual server must belong to a domain. If the domain to which it belongs has a Kerberos realm bound to it (see previous step), the virtual server can optionally participate and use Kerberos to authenticate clients. In addition, down-level clients (clients that are not capable of Kerberos authentication) can still authenticate themselves, as long as the Windows Domain Security Policy for the CIFS domain has been set appropriately and does not restrict authentication.
The following example creates a CIFS virtual server that uses Kerberos to authenticate clients.
Server1::> spinaccess cifs servers new -vsname myvs0 -nbname MYCIFSSRV0 -domainname MYDOMAIN -visibledomains [MYDOMAIN, MYOTHERDOMAIN] -nodetype H -usekerberos Yes -kerbprivuser Administrator -kerbprivpass secret
where
myvs0 is the name of an existing virtual server that is to be enabled for CIFS access.
MYCIFSSRV0 is the NetBIOS name for the virtual server that is advertised on the local network. NetBIOS names must be unique on their subnet. Another host on any subnet in which the virtual server has a virtual interface must not use this name. The name is advertised in all subnets. A name conflict in any of them is difficult to discover.
MYDOMAIN is the domain to which the virtual server belongs. The domain that is specified with this command must already have been created, and must be enabled for Kerberos access. See Section 6.8.2.
[MYDOMAIN, MYOTHERDOMAIN] is a square-bracketed, comma-separated list of domains that are considered trusted domains that enable users from those domains to be authenticated and granted access to the SpinServer. Users from domains not listed in the visible domains are not granted access to the SpinServer, even though those domains have a Windows trust relationship with one another.
H is the NetBIOS node type, which is a way of specifying how the CIFS virtual server announces itself to hosts on the subnet. For more information see RFCs 1000 and 1001. Other possible values for the NetBIOS node type are B, P, and M.
Yes specifies that Kerberos is used to authenticate users. See the previous section for details on how to create a Kerberos realm.
Administrator is the name of an account that has sufficient privileges to create Service Principal Accounts in the Active Directory for the domain. This account need not be the administrator for the domain, but often this account is the only account that has been granted the required privilege.
secret is the password for the account specified by the value of the -kerbprivuser parameter. The password is echoed in clear text to the CLI console; it is therefore recommended that you perform the entire CIFS virtual server creation step from the GUI. The GUI masks the password as it is entered.
For more information, see Section 14.2.2.1.
This section provides instructions on setting up export rules and rule sets. Export rules and rule sets enable you to require different levels of authentication based on client IP addresses.
The following steps are involved in setting up export rule sets:
Create an export rule set, as described in Section 6.12.1.
Add rules to the rule set, as described in Section 6.12.2.
Configure one or more VFSs to use the rule set, as described in Section 6.13.
An export rule set holds export rules; each rule set can hold approximately 8,186 rules. Each VFS is associated with exactly one rule set. Each rule set is identified by a unique name and a unique numeric ID. A SpinCluster can contain up to 1,024 rule sets. Each cluster has at least one rule set with ID 0, which contains no rules; every VFS in the cluster is, by default, associated with this rule set. This rule set cannot be deleted, although it can be renamed or modified. A newly installed or upgraded cluster contains only the default rule set.
Use the spinaccess exportrule new command to create a new export rule set. The following example creates an export rule set named rs0:
Server1::> spinaccess exportrule new -rulesetname rs0
For more information, see Section 16.2.6.1.
Use the spinaccess exportrule addrule command to add a rule to an export rule set that was created by using the spinaccess exportrule new command. To add a rule, you need to specify the name of the rule set, the client IP address or netgroup name to which the rule applies, the network mask that the rule must match (if a client IP address is specified), the strength of the read-only rule, and the strength of the write rule. The strengths of the read-only and write rules, listed in order of increasing strength, are as follows:
any—A matching client can access the VFS regardless of authentication strength.
cifs-ntlm—A matching client can access the VFS if it is authenticated by CIFS NTLM or a stronger mechanism.
cifs-kerberos—A matching client can access the VFS if it is authenticated by CIFS Kerberos or a stronger mechanism.
nfs-kerberos—A matching client can access the VFS if it is authenticated by NFS Kerberos or a stronger mechanism.
never—Matching clients cannot access the VFS.
Note: Write access is contingent upon read-only access, so specifying a value for the -rwrule parameter that is not as strong as the value of the -rorule parameter has no effect. For example, if you give the settings -rorule nfs-kerberos -rwrule any, CIFS clients cannot access the VFS in any way, even though the value of the -rwrule parameter is any.
To specify a client IP address, enter the IP address as the value of the -clientmatch parameter and specify a netmask by using the -netmask parameter. To specify a netgroup, specify the netgroup as the value of the -clientmatch parameter in the form @netgroup_name, and do not specify the -netmask parameter.
The following example adds an export rule to the rule set named rs0. The rule applies to the client IP address 192.55.0.0, and the network mask 255.255.128.0 is used to match the rule. Rules that are completely redundant are rejected by the SpinServer. The rule permits read-only access to any matching clients, but requires that matching clients have nfs-kerberos authentication to write files.
Server1::> spinaccess exportrule addrule -rulesetname rs0 -clientmatch 192.55.0.0 -netmask 255.255.128.0 -rorule any -rwrule nfs-kerberos
For more information, see Section 16.2.6.6.
The root VFS for a virtual server is automatically created when a virtual server is created. The file system for a particular virtual server can be expanded beyond this single VFS by creating additional VFSs and linking them together by using the filestorage vfs mount command.
Note: By default, the root VFS has a maximum quota of 10 MB. You can expand its quota by using the filestorage vfs modify command.
To create a VFS and set quotas for it, use the filestorage vfs new command.
Minimum and maximum quotas can be specified when creating a VFS. A quota refers to the amount of data storage on a VFS and is specified in units of 1-MB blocks.
The minimum quota guarantees that the specified amount of storage is available. This is done by reserving storage from the underlying storage pool. The maximum quota limits the amount of data that can be written to a VFS, but no reservation is made. Oversubscription is possible. The quotas can be modified at any time.
The following example creates of a VFS named vfs0 for the virtual server vs0 on storage pool sp0 with a 5000-MB minimum quota and 10000-MB maximum quota.
Note: You cannot use the same VFS name or ID on multiple, different virtual servers. VFS names or IDs must be unique to a cluster.
Server1::> filestorage vfs new -vfsname vfs0 -vsname vs0 -mounttype context -mountpath /vfs1 -qmin 5000 -qmax 10000 -freespacealarm 10 -spdevid sp0 -usertype SPIN -domain 0 -user 0 -group 0 -rulesetname rs0 -showspinshot true -restrictedacl false
where
vfs0 is the name or ID of the virtual file system.
vs0 is the name or ID of the virtual server.
context specifies that this VFS inherits the context (read-write or read-only) from its parent VFS.
/vfs1 is the mount path for the VFS.
5000 is the minimum quota, specified in MB.
10000 is the maximum quota, specified in MB.
10 is the percentage of free space remaining on the VFS when the free-space alarm is triggered.
sp0 is the name or ID of the storage pool.
SPIN is the type of the user. This is a generic user type that is used for initial setup procedures. Use the SPIN user type if there is not an NIS or CIFS domain configured or available.
0 is the name or ID of the domain.
0 is the name or ID of the user.
0 is the name or ID of the user's group.
rs0 is the name of the export rule set that is applied to this VFS.
true specifies that this VFS's .spinshot directory is visible to clients.
false specifies that CIFS ACLs are used on files on this VFS.
For more information, see Section 13.2.2.
Any number of VFSs can be created on a given storage pool. Each VFS can be mounted in another VFS. If you do not specify the mount path by using the -mountpath parameter of the filestorage vfs new command when the VFS is created, use the filestorage vfs mount command to create a mount path for the virtual file system, as in the following example. The VFS is not accessible until it is mounted.
Server1::> filestorage vfs mount -vfsname vfs0 -mounttype explicit -mountpath /vfs0 -expoverride false
where
vfs0 is the name or ID of the virtual file system.
explicit is the type of VFS that is to be mounted. Possible values are context (for a VFS that inherits the type of the VFS that it is mounted on), explicit (for a read-write VFS), mirror (for a read-only mirror), and clone (for a read-only clone).
/vfs0 is the mount path of the virtual file system. You access the VFS by this path from root (/).
false specifies that the VFS's associated export rule set is not overridden.
For more information, see Section 13.2.3.
To enable the SpinServer for the CIFS protocol, complete the following tasks:
Define the CIFS domain in which the virtual server resides. This task is described in Section 6.8.2.
Create a CIFS server. This task is described in Section 6.11.2.4.
Bind virtual interfaces to the CIFS server.
Create CIFS shares.
To complete the CIFS tasks, you must obtain configuration information from your network administrator. Use the following table to enter the information that is needed for this process.
| CIFS domain name or ID | |
| CIFS domain's WINS server IP address | |
| CIFS domain's primary domain controller name | |
| CIFS domain's primary domain controller IP address | |
| CIFS domain's backup domain controller name | |
| CIFS domain's backup domain controller IP address | |
| Virtual server name or ID | |
| Visible domain names or IDs | |
| NetBIOS name | |
| Node type | |
| Share name or ID | |
| Share's directory path |
Note: For detailed information on CIFS and CIFS-to-NFS mappings, see Chapter 14 and Chapter 15.
For the CIFS command examples that follow, sample information obtained from a network administrator is provided.
| CIFS domain name or ID | ENG |
| CIFS domain's WINS server IP address | 10.1.1.116 |
| CIFS domain's primary domain controller name or ID | STORM |
| CIFS domain's primary domain controller IP address | 10.1.1.116 |
| CIFS domain's backup domain controller name or ID | RAIN |
| CIFS domain's backup domain controller IP address | 10.1.1.118 |
| Virtual server name or ID | VS0 |
| Visible domain names or IDs | MARKETING, ENG |
| NetBIOS name | NB0 |
| Node type | M |
| Share name or ID | ENG_BILL |
| Share's directory path | /development/engineering |
To share data via the CIFS protocol, a CIFS share must be created. The spinaccess cifs shares new command node enables you to define a share, which essentially defines the directory within the file system that is accessible to Windows clients. Multiple shares can be created on a single virtual server.
The following example creates a new CIFS share.
Server1::> spinaccess cifs shares new -vsname VS0 -sharename ENG_BILL -path /development/engineering -remark "This is a new share for VS0"
where
VS0 is the name or ID of the virtual server to which the share is added.
ENG_BILL is the name of the share to be added.
/development/engineering is the directory path that is to be shared. This path must exist in the virtual file system.
"This is a new share for VS0" is the description for the share that is to be made available to Windows clients as a comment. This parameter is optional.
For more information, see Section 14.2.3.1.
To verify network connections, use the Linux ping and traceroute commands.
Copyright © 2004 Network Appliance, Inc.; copyright © 2003, 2004 Spinnaker Networks, LLC. All rights reserved. Specifications subject to change without notice.